home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20041116-20060924
/
000394_rock_spambust_violin@yahoo.com_Sun Aug 20 15:41:54 2006.msg
< prev
next >
Wrap
Internet Message Format
|
2006-09-27
|
3KB
Path: reader2.panix.com!reader1.panix.com!panix!newsfeed.media.kyoto-u.ac.jp!newsfeed.icl.net!newspump.monmouth.com!newspeer.monmouth.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!74g2000cwt.googlegroups.com!not-for-mail
From: "tomviolin" <rock_spambust_violin@yahoo.com>
Newsgroups: comp.protocols.kermit.misc
Subject: extremely high latency channel
Date: 10 Aug 2006 12:55:57 -0700
Organization: http://groups.google.com
Lines: 39
Message-ID: <1155239757.815134.180170@74g2000cwt.googlegroups.com>
NNTP-Posting-Host: 129.89.149.197
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1155239763 23345 127.0.0.1 (10 Aug 2006 19:56:03 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 10 Aug 2006 19:56:03 +0000 (UTC)
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: 74g2000cwt.googlegroups.com; posting-host=129.89.149.197;
posting-account=ornCOQwAAAAyCG4a7NOAj_SMr54FiqNu
Xref: panix comp.protocols.kermit.misc:15525
I am communicating with a remote system (a buoy) using MaxStream 900MHz
radios. Due to various circumstances, the latency on the line is very
high, up to 30 seconds sometimes. Often I'll press return at the unix
or Kermit prompt several times, and 20-30 seconds later the several
prompts will appear. Same thing with echoes of typing.
However, due to the error checking of the radios, the line is rather
reliable. Occasionally some data gets lost, but most of the time it
all gets through.
Also, if you try to send something while the other side is trying to
send, it causes extra delays, and that is where data is lost most of
the time.
Our major problem is trying to tweak the Kermit protocol to deal with
this. Ultimately, if the system could send a packet, PATIENTLY wait
for an acknowledgement without trying to send anything (and only after
a minute or so attempt a retry), it would probably work OK.
As it is, we get extremely dismal throughput, even on ROBUST setting,
because it seems I can't get Kermit to wait patiently enough for a
response. I've tried to set the send and receive timeouts to high
values (like 60) but I keep seeing messages about timeouts of 15
seconds or less during the transfer attempts.
We've gotten much better results simply using "cat" to display the
files and using session logging to capture the text. But I should
think that a protocol as versatile as Kermit could do better than
"cat". I've even tossed around the idea of tacking checksums to the
end of the files and doing my own error checking in script. But that
seems so silly because the Kermit protocol should be able to handle
this.
Does anyone have any hints here? What's particularly frustrating is
that the interactive command prompt experience over this link isn't all
that bad, it just usually takes a few seconds for things to echo.
Thanks for any tips.